Methods and systems for automated generation of bills

ABSTRACT

The present invention provides methods and systems for processing bills electronically. Generally, a bill is created for a customer using billing information and master data from a biller and master data from a customer. Billing information is received from the biller by a first processing module having access to the master data of the biller. The first processing module generates a bill using the billing information and the master data of the biller. A second processing module having access to the master data of the customer provides customer data to the first processing module. The bill is transformed into a format specified in the master data of the customer by the first processing module if the format of the generated bill is not the format specified in the master data of the customer. The generated or transformed bill is transferred to the second processing module by the first processing module.

RELATED APPLICATIONS

This U.S. patent application is a continuation of U.S. patentapplication Ser. No. 13/222,222, filed Aug. 31, 2011, which is acontinuation of U.S. patent application Ser. No. 12/790,003, filed May28, 2010, now U.S. Pat. No. 8,032,458, which is a continuation of U.S.patent application Ser. No. 10/651,545, filed Aug. 29, 2003, now U.S.Pat. No. 7,761,377, which claims the benefit of U.S. Provisional PatentApplication No. 60/406,986, filed Aug. 30, 2002, European PatentApplication No. 02027089.8 filed Dec. 3, 2002, European PatentApplication No. 02027090.6 filed Dec. 3, 2002, and German PatentApplication No. 10256152.4 filed Nov. 29, 2002, all of which areincorporated herein by reference.

FIELD OF THE INVENTION

The technical field of this invention is electronic data processing.More particularly, the invention relates to methods, computer programs,computer program products, and systems for automated billing systemsand, still more particularly, for processing, generating and presentingan electronic invoice to a customer for remote review and payment.

DESCRIPTION OF THE RELATED ART

It should be understood that the term “presentment” as used herein doesnot include the specialized definition normally associated withcommercial paper, i.e. the production on a negotiable instrument to adrawee. Rather, the term refers to providing via electronic meansinformation, particularly an “invoice,” containing at least the samecustomer billing data typically included on a paper invoice. Thiselectronic presentment may preferably, but not exclusively, take placethrough the use of an internet- or intranet website or via email or SMS,such as, for example, by making a web site accessible to one or morepersons. It may further take place by sending computer-readable storagemedia, like disks, ZIP disks, magneto-optical disks, CD-, CDRW-, DVDROMs or other similar materials via standard mail.

There exist many known methods and systems for electronic billpresentment and payment (EBPP) in enterprise resource planning (ERP)software environments. For example, U.S. Pat. No. 6,044,362 discloses asystem for automated electronic invoicing and payment for providingremote customer review of automated billing from an invoicer. The systemincludes invoice presentment electronics having a control system andfirst communication electronics. The system also includes at least oneremote authorization terminal having a customer interface, the terminalhaving second communication electronics adapted to operativelycommunicate with the first communication electronics. The control systemof the invoice presentment electronics is adapted to provide billingdata, regarding a customer invoice preauthorized for automated billing,to the first communication electronics for transmission to the secondcommunication electronics. The customer interface of the remoteauthorization terminal is adapted to present the billing data to acustomer and to receive a response relating to the billing data from thecustomer, the response indicating one of acceptance of the billing datafor automated billing or modification of the billing data for modifyingautomated billing. Acceptance can either be an active response from thecustomer or a passive response such as, for example, automaticacceptance up to a preset limit.

U.S. Pat. No. 5,465,206 discloses a bill pay system whereinparticipating customers pay bills to participating billers through apayment network operating according to preset rules. The participatingcustomers receive bills from participating billers of (paper/mail bills,e-mail notices, implied bills for automatic debts) which indicate anamount, and a unique biller identification number. To authorize aremittance, a customer transmits to its bank (a participating bank) abill pay order indicating a payment date, a payment amount, thecustomer's account number with the biller, a source for the funds, andthe biller's biller identification number, either directly or byreference to static data containing those data elements. The bank thensubmits a payment message to a payment network, and the payment network,which assigns the biller reference numbers, forwards the payment messageto the biller's bank. For settlement, the customer's bank debits thecustomer's account and is obligated to a net position with the paymentnetwork; likewise, the biller's bank receives a net position from thepayment network and credits the biller's bank account. If the customer'sbank agrees to send non-reversible payment messages, the customer's bankdoes not submit the transaction until funds are good unless thecustomer's bank is willing to take the risk of loss if funds are notgood, such as in the case of a guaranteed payment network. The biller'sbank, upon receipt of the payment message, releases the funds to thebiller, and provides A/R data to biller in a form which the biller hasindicated, the form being one which does not have to be treated as anexception item to the biller. The biller's bank is assured of payment bythe payment network, unless the transaction is a reversible transactionaccording to the preset rules of the payment network. In specificembodiments, the customer initiates the bill pay orders manually, viapaper at an ATM, via PC, or via telephone keypad.

Another system is known from the website www://ofx.net. Open FinancialExchange (ofx) is a broad-based framework for exchanging financial dataand instructions between customers and their financial institutions. Itallows institutions to connect directly to their customers withoutrequiring an intermediary. Open Financial Exchange is an openspecification that anyone can implement: any financial institution,transaction processor, software developer, or other party. It useswidely accepted open standards for data formatting (such as XML),connectivity (such as TCP/IP and HTTP), and security (such as SSL). OpenFinancial Exchange defines the request and response messages used byeach financial service as well as the common framework andinfrastructure to support the communication of those messages. The dataof biller and customer are held in the same system.

In systems that use a direct contact between biller and customer,however, it is difficult to technically implement a business scenario inwhich bills of different billers are presented to one customer. Further,it is difficult to integrate and maintain such systems in the IT(information technology) systems of billers and customers, particularlyif a high bill volume has to be handled.

Thus, there is a need for a method, software application, and/or dataprocessing system that provide a more efficient solution to some or allof the problems described above, that is, methods and systems for moreefficient bill processing.

SUMMARY OF THE INVENTION

In accordance with the present invention, as embodied and broadlydescribed herein, methods and systems consistent with the principles ofthe invention provide a method for processing bills electronically,wherein a bill is created for a customer using billing information andmaster data from a biller and master data from a customer. Billinginformation is received from the biller by a first processing modulehaving access to the master data of the biller. A bill is generated bythe first processing module using the billing information and the masterdata of the biller. A second processing module having access to themaster data of the customer is requested to provide customer data to thefirst processing module. The bill is transformed into a format specifiedin the master data of the customer by the first processing module if theformat of the generated bill is not the format specified in the masterdata of the customer. The generated or transformed bill is transferredto the second processing module by the first processing module.

Another aspect of the invention is to provide a computer system forprocessing bills electronically, wherein a bill is created for acustomer using billing information and master data from a biller andmaster data from a customer. A computer system consistent with thepresent invention comprises a memory having program instructions, aninput means for receiving and entering data, an output means for sendingand presenting data, a storage means for storing data, and a processorresponsive to the program instructions. The processor receives thebilling information from the biller by a first processing module havingaccess to the master data of the biller and generates a bill by thefirst processing module using the billing information and the masterdata of the biller. The processor also requests data of the customerfrom a second processing module having access to the master data of thecustomer by the first processing module and transforms the bill into aformat specified in the master data of the customer by the firstprocessing module if the format of the generated bill is not the formatspecified in the master data of the customer. The processor alsotransfers the generated or transformed bill to the second processingmodule by the first processing module.

Methods and systems consistent with the present invention providesolutions for providing a large amount of bills in an efficient way to aspecific customer. A plurality of billers can provide their billinginformation to the first module. The billing information is transformedinto a bill in a format specified by the respective customer.

The present invention is further directed to a computer system, acomputer program, a computer-readable medium and a carrier signal, eachcomprising program code or instructions for processing bills accordingto the inventive method and in its embodiments.

Each of the processing modules may be installed as computer programs ondifferent hardware systems (computers or computer systems), and runseparately and independently of each other. The different systems may beconnected in the form of a network to communicate with each other. Inaddition, one or more of the processing modules may be a part of(integrated in) another processing module.

Additional objects and advantages of the invention and its embodimentswill be set forth in part in the description, or may be learned bypractice. It is understood that both the foregoing general descriptionand the following detailed description are exemplary and explanatoryonly and are not restrictive of the invention, as claimed.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings, which are incorporated in and constitute apart of this specification, illustrate embodiments of the invention and,together with the description, explain the principles of the invention.In the drawings,

FIG. 1 is a schematic block diagram of one exemplary implementation ofthe inventive method within a computer system,

FIG. 2 is an block diagram of one exemplary implementation of theinventive method,

FIG. 3 shows an overview of an example of an inventive electronic billpresentment and paying system consistent with the present invention,

FIG. 4 is a block diagram of one exemplary interconnection of a firstand second processing module,

FIG. 5 is a flow diagram of one exemplary inventive billing processconsistent with the present invention,

FIG. 6 is a flow diagram of an exemplary inventive bill presentmentprocess consistent with the present invention,

FIG. 7 is a flow diagram of an exemplary process for registering acustomer for an inventive electronic billing process consistent with thepresent invention,

FIG. 8 is a flow diagram of an exemplary process for activating aregistering of a customer by a biller consistent with the presentinvention,

FIG. 9 is a block diagram of an exemplary table for mapping the IDs of abiller for a customer to the IDs of a customer for a biller,

FIG. 10 is a block diagram showing integration of e-banking into anelectronic bill presentment and paying system consistent with thepresent invention,

FIG. 11 is a flow diagram of an exemplary process for initiating andperforming a bill review by a customer consistent with the presentinvention,

FIG. 12 is the continuation of the flow diagram in FIG. 11, and

FIG. 13 is a block diagram of an exemplary archiving process for data ofbillers or customers.

DETAILED DESCRIPTION

Computer systems and the programs that control them are closely related.As used herein, phrases such as “the computer provides,” “the programprovides or performs specific actions”, and “a user performs a specificaction” are used to describe actions by a computer system that arecontrolled by a program or to indicate that the program or programmodule is designed to enable the computer system to perform the specificaction or to enable a user to perform the specific action by a computersystem. A computer system can be a stand-alone computer, such as a PC ora laptop, or a series of computers connected as a network, such as anetwork within a company or a series of computers connected via theinternet.

Processors suitable for execution of a computer program consistent withthe present invention include, by way of example, both general andspecial-purpose microprocessors, and any one or more processors of anykind of digital computer. Generally, a processor will receiveinstructions and data from a read-only memory or a random access memoryor both. Generally, a computer comprises a processor for executinginstructions and one or more memory devices for storing instructions anddata. Generally, a computer will also include, or be operatively coupledto receive data from or transfer data to, or both, one or more massstorage devices (storage means) for storing data, e.g., magnetic,magneto-optical disks, or optical disks. Information carriers suitablefor embodying computer program instructions and data include all formsof non-volatile memory, including by way of example semiconductor memorydevices, such as EPROM, EEPROM, and flash memory devices; magnetic diskssuch as internal hard disks and removable disks; magneto-optical disks;and CD-ROM and DVD-ROM disks. The processor and the memory can besupplemented by, or incorporated in, ASICs (application-specificintegrated circuits).

To provide for interaction with a user, the present invention can beimplemented on a computer having a display device such as a CRT (cathoderay tube) or LCD (liquid crystal display) monitor for displayinginformation to the user and a keyboard and a pointing device, such as amouse or a trackball, by which the user can provide input to thecomputer. Other kinds of devices can be used to provide for interactionwith a user as well. For example, feedback may be provided to the userin the form of sensory feedback, such as visual feedback, auditoryfeedback, or haptic feedback; and input from the user can be received inany form, including acoustic, speech, or haptic input.

Reference will now be made in detail to the principles of the inventionby explaining the invention as a data processing process, examples ofwhich are illustrated in the accompanying drawings. The examplesmentioned herein are intended to explain the invention and not to limitthe invention in any kind

The first processing module is hereinafter referred to as “billerservice provider” (BSP), the second as “consolidator,” and the third asthe “customer service provider” (CSP). If the CSP is integrated in theconsolidator, the resulting combination is referred to as “integratedCSP” (iCSP).

FIG. 1 depicts one exemplary implementation of an embodiment of theinvention, that is, a computer system with program modules forperforming the inventive method. FIG. 1 shows a computer system 101comprising a computer 103 having a CPU 105, a working storage 112(memory), in which software applications are stored for processing byCPU 105. The software applications comprise program modules 110, 106,109 for carrying out the first, second and third processing modules,respectively, according to the inventive method.

Computer system 101 may further comprise input means 117, output means102 for interaction with a user, such as for starting the programmodules and/or for data input, and general input/output means 104,including a net connection 114, for sending and receiving data, such asdata on billing information, bills, payment orders, customer and billermaster data. A plurality of computer systems 101 can be connected vianet connection 114 in the form of a network 113. In such a case, each ofthe modules 106,109,110 may be installed and run separately and/orindependently on the respective network computers 113. In this case, thenetwork computers 113 can be used as further input/output means,including as storage locations. Computer system 103 may further comprisea first storage means 107, in which master data of the customer may bestored, and a second storage means 108, in which the master data of thebiller may be stored.

In at least one embodiment of the present invention, first processingmodule 110 (BSP) has access to the master data of the biller stored onstorage means 108, and the second processing module 106 (consolidator)has access to the master data of the customer stored on the storagemeans 107. A biller 111 and a customer 115 may be connected, permanentlyor on an as-needed basis, to computer system 103 via input/output means104. A further connection may be established to a payment service 116.The interactions of biller 111 and customer 115 with the accompanyingprogram modules 110, 109, respectively, are indicated by dashed arrowsas is the affiliation of the BSP and the consolidator to the respectivestorage means 108, 107.

FIG. 2 illustrates one example of a network connection of severalprogram modules of BSPs 201 a, 201 b, consolidators 202 a, 202 b, 202 c,and a CSP 203, each of which is installed on a separate computer system204 a,b, 205 a,b,c and 208. The respective computer systems may beidentical or different from each other, depending on the requirements ofthe application case. The computer systems may be located in differentcountries in the world. One or more billers can have access to thatnetwork via computer systems 206 a,b by, for example, using web browsers207 a,b. These computer systems 206 a,b may be connected to each of theBSPs 204 a,b. A customer can have access to the network via a computersystem 210 having a web browser 211. For performing the paymentsassociated with the bills, an computer system 209 of a payment serviceprovider having an e-banking application may be connected to one or moreof the consolidator systems 205 a,b,c.

According to the inventive concept of separating the biller master datafrom the customer master data, as many BSPs as necessary can beconnected to one consolidator. This avoids superfluous movement of data,because the customer master data need not be shifted or copied to themodule which processes the bills, as would be necessary using most priorart methods. With this concept, billing volumes of over several millionbills per month can be handled by using several BSPs connected to oneconsolidator, for example. If customer master data needs to be updated,only the data base of the consolidator needs to be changed in systemsconsistent with the present invention. The BSP data base is not affectedby such an update. A further effect is that, in most if not allapplications, maintenance costs for the master data are reduced.

FIG. 3 provides an overview of possible formats and interfaces for thedata exchange between a biller and the BSP, the BSP and theconsolidator, the consolidator and the CSP, and between the CSP and acustomer (payer). As shown in FIG. 3, the biller side may be split intothree cases: Large billers using an SAP ERP system (such as one providedby SAP AG, D-69190 Walldorf, Germany), large billers using a non-SAP ERPsystem, and small billers. In this example, the terms “large” and“small” refer to the turnover of the respective company or person and ismeant to be exemplary. The same cases may be found on the customer side.In FIG. 3, the CSP is shown in the example for large payers integratedin the consolidator as iCSP and for the small payers it is a separateprogram module with two alternative implementations, SAP Portals CSP andOnline Banking CSP.

In this example, the BSP supports four formats for the billinginformation: the IDOC, FLATFILE, EDIFACT, and a predefinable BSP formaton which the systems of the biller and the BSP have to be adapted duringthe installation of the respective software. The systems in the billerside may communicate with the BSP using, for example, HTML, HTTPS,XML-IDOC (SSL), FLAT (SSL), EDI (SSL). The BSP and the consolidator maycommunicate via XML, as well as consolidator and CSP. The CSP and/oriCSP may communicate with the systems of the customer using, forexample, HTML (HTTPS), XML-IDOC (SSL), EDI (SSL) and XML.

FIG. 4 shows an example of possible interfaces (IF) with which the BSPand/or CSP and/or iCSP may be provided: a biller or customer EDI/fileIF, Web GUI (graphical user interface), BCX, Flat File Conversion, PrintIF, Archiving IF, a Cost Event IF for connection with a billing engine,an IF for connection with a payment service (financial institution) or aCCX IF for connection with an internet service provider (ISP). In orderto view its list of bill summaries, the biller can connect to the BSP.The customer can connect directly to the CSP/iCSP or indirectly via aconnection to financial institutions or ISPs. For itemized bills andregistration, the customers may connect to the BSP.

The BSP may store all data associated with the biller in a partner database. The partner data base may include, for example, master data of thebillers comprising addresses, identification keys, authorizations,biller's integration level (interfacing capabilities and implementedprocesses), logos, location of the logos on the bill, advertisementforms for personalized promotions, formats for credits, digitalsignatures, etc. The billing information, the generated and/ortransformed bills, and bill details for web presentment may be stored,for example, by the BSP in a business object data base. A businessobject in this sense may comprise all data belonging to a businesstransaction that is the cause for the specific bill. Typical billinginformation comprises, for example, the article, type of article,article number, number of the articles, position, ID, description ofarticle, price, tax information, addresses (such as for delivery),references (URLs for details), dates (such as billing, shipping, orreceipt date) etc.

The consolidator/iCSP may store all data associated with the customerand the financial institutions in a partner data base. For example, thepartner data base may comprise master data of the customer including thecustomer's address, addresses for communication within the customer'sorganization and between the customer and the biller, a format in whichthe bill shall be presented, addresses for providing status information,dispute results, or review management, identification keys,authorizations, digital signatures, etc. Consolidated or aggregatedbills or bill summaries to be presented to the customer may be stored bythe consolidator/iCSP in a consolidator's business object data base. Asmany BSPs as necessary to handle the bill volume may be connected to aconsolidator/iCSP in such a way.

In at least one exemplary embodiment, program modules 106, 109, 110 areprocessed by CPU 105 in FIG. 1 in order to carry out the inventivemethod. In this example, steps as described in the following section maybe performed by the computer system 101 or the systems of the network asdescribed above.

FIG. 5 shows a flow diagram of an exemplary implementation of aninventive process. The time axis in FIG. 5 runs from top to bottom. Asshown in FIG. 5, a biller may send billing information to the BSP (step505). The biller may send such information using an ERP computer system.The biller may also send the billing information in a format agreed uponwhen the biller registered with the BSP. The BSP may create a bill andassign a status of “new” to that object (step 510). The new bill may becreated based on the received billing information, the biller's masterdata, or a combination thereof. The new bill may be in paper orelectronic form. The BSP may then send a request for information aboutthe customer (CustomerInfoRequest) to the Consolidator/iCSP (step 515).The consolidator/iCSP may respond to that request and return to the BSPavailable data from the customer master data base for the inquiredcustomer (CustomerInfoResponse) (step 520). In addition to theinformation given above, the response may contain other information,such as whether a customer requests billing data for web presentment(so-called “thin” consolidation because only the main information ispresented to the customer), for processing in an ERP system (also called“thick” consolidation because the bill sent electronically to thecustomer includes bill details), in a digitally-signed format accordingto applicable tax or other legal regulations, or in an encrypted format.In at least one embodiment, the response may contain information on thebiller-to-customer relationship (BCR) regarding their respective IDs intheir respective ERP systems. In at least one embodiment, the responsemay contain authentication information for accessing itemized bills orfor encryption (such as a list of digital IDs, distinguished names,certificate serial numbers, or other information referencing X.509certificates).

The BSP may then transform the bill into the format received with theCustomerInfoResponse. In certain embodiments, it is recommended thatdata be converted from the source to the destination format as close tothe source as possible. If possible, conversions should be avoided, asconversions generally increase the risk of data loss. In certainembodiments, a BSP may use external conversion services. A BSP may useexternal conversion services if, for example, a destination format cannot be produced internally or if using external conversion services isotherwise advantageous. For example, a BSP may choose to use externalconversion services if doing so allows the BSP to digitally sign thebills in a manner conforming to government regulations for VATdeductions. The customer may directly process and archive the invoice inone simple integrated process. In certain embodiments, the presentinvention may allow application content to be preserved easier. Inaddition, if the total number of supported formats is small, the amountof transformation work and costs may be reduced. Adaptations toaccommodate differences between the specific formats required by eachPayment Service Providers (PSP) can be handled in the consolidator/iCSP.

In conventional EBPP systems, conversion is often done indirectly usingan intermediate (“in-house”) format. Source data is first converted intothe in house format and then converted into the destination format.Using this technique, the number of conversions is linear (2n) withrespect to the number of formats (n), compared to n(n−1) conversions inthe case of direct conversions. However, even though an intermediateformat can also be used in the conversion on the present BSP, theconversion to the customer format should happen as early as possible inthe presentment process.

By converting the invoice to the end user format at the BSP, the billcan be signed at the BSP. If the payment formats are converted to Billerand Customer formats on the consolidator, only the consolidator willneed knowledge of the various payment formats required by each PSP. TheBSP and CSP may remain independent of payment formats.

If implemented on a hardware system of a third party, the BSP may beconsidered an outsourcing partner of the biller, which may beadvantageous in certain situations. Similarly, implementing the CSPand/or the consolidator/iCSP on third party hardware may also beadvantageous in certain situations. In certain embodiments, for example,the BSP may produce the bills (electronic and/or paper) on behalf of thebiller. If necessary, the biller as a legal entity may need to assignthe right to digitally sign bills to the legal entity that operates theBSP. The BSP may then be responsible for producing a digitally-signedinvoice message in a format accepted, readable, and processable by thecustomer and valid for VAT deduction. This is achieved by, for example,using the conversion process described above.

In certain embodiments, the customer may check to see that the BSP hasthe authority for issuing invoices on behalf of the biller. For example,a list of billers (see Customer Registration for E-Bills) may be postedon the Internet with hyperlinks to one or more documents that indicatethat the BSP has the necessary authority. For added security, thedocuments may be digitally signed by the biller.

In many European countries, until recently, customers has to present toauthorities a paper invoice in order to obtain a refund of VAT (ValueAdded Tax) for purchased goods. The invoice document had to be printedby the biller and contain certain required information. Other forms ofinvoices, such as electronically transferred bills printed by thecustomer, were not accepted. In the European Union and other countries(such as Switzerland), new laws and regulations allow VAT deduction onelectronically transmitted bills, if they are digitally signed by thebiller. The certificate and the procedure used for signing areregulated.

In order to generate an invoice in the requested format, the BSP mayhave access to external conversion services such as, for example, a webservice. In this case, the bill to be presented to the customer may beprepared by the external conversion services. If the customer cannot bereached electronically, that is, for example, if theCustomerInfoResponse returns “unknown”, the BSP can generate a paperbill and/or inform the biller accordingly.

Each invoice may be associated with an invoice delivery date, that is, adate when the invoice should be transmitted to the customer. When aninvoice delivery date is reached, the BSP delivers the transformed billto the consolidator/iCSP (InvoiceDeliveryRequest) (step 525).Alternatively, if no invoice delivery date is associated with theinvoice, the BSP may deliver the transformed bill to theconsolidator/iCSP immediately or at periodically scheduled times.Additionally, the BSP may submit to the consolidator/iCSP information onthe integration status of the biller (for example, BillerPreferences,I-Summary, I-Details). This information may be used by theconsolidator/iCSP to perform operations on the received transformedbill. For example, the consolidator/iCSP may use such information whenprocessing a request for credit, determining the status of a bill (suchas, for example, if a bill has been delivered or paid), or in processingother types of inquiries related to the billing process such as disputeresolution. The consolidator/iCSP may indicate to the BSP that atransformed bill is available for access by the customer (by, forexample, sending an InvoiceDeliveryResponse) (step 530). The BSP maythen change the status of the bill to indicate that it is ready to bedelivered (step 535). The consolidator/iCSP may then change the statusof the received transformed bill to indicate that it is ready to beopened (step 540).

At this point, the next steps in the process may depend on certainfactors such as whether the customer is a web customer or an ERPcustomer, whether payment preferences are applicable to the specificcustomer, or on the connection status of the biller's and customer'sPSP. In certain embodiments, web presentment and payment may be handledusing a banking portal (CCX IF), an Internet Service Provider (ISP) anda PSP, an ERP connection and payment using a payment channel, or an ERPconnection and payment using an SAP EBPP system.

In step 545, the bill is “delivered” to the customer. “Delivery” mayinvolve the consolidator/iCSP transmitting the bill to the customer orthe customer retrieving the bill. For example, in certain embodiments,the customer may access the transformed bill via a web portal on theconsolidator/iCSP data base. In certain embodiments, the process mayinvolve additional optional steps such as verifying the invoice,crosschecking the information in the invoice with materials managementinformation, or checking with payment processing systems.

In step 550, a payment order is sent to the consolidator/iCSP. Incertain embodiments, the payment order may be digitally signed by thecustomer or other vouching entity. The consolidator/iCSP may then passpayment scheduling information to the BSP (SetEBPPStatusRequest) (step555), which with BSP may use to schedule the payment (step 560). Incertain embodiments, the BSP may mark the payment for immediate payment.The BSP may optionally inform the biller about the scheduled payment(step 562). Immediately or at a requested payment date, theconsolidator/iCSP generates a payment order in a format required by thePSP and sends the payment order to the PSP (step 565). The payment ordermay be cryptographically authenticated. The PSP processes the payment,either a debit (570) or a credit (575) and may use interbank paymentprocessing to do so, if required or desired. The consolidator/iCSP mayoptionally send a debit notice to the customer (step 580). Theconsolidator/iCSP may generate the debit notice in a format the customerrequires and sends the message to the customer. The status of thetransformed bill in the consolidator/iCSP is set to paid (step 585). Theconsolidator/iCSP may then send a credit notice to the biller. Theconsolidator/iCSP may generate a credit notice in a format requested bythe biller and send that message together with a status change requestto the BSP (SetEBPPStatusRequest) (step 590). The BSP may change thestate of the bill to “paid” (step 595) and send a credit notice to thebiller (step 598).

FIG. 6 is a flow diagram of an exemplary inventive bill presentmentprocess consistent with the present invention. The customer or a userlogs in at the CSP/iCSP (step 610). The customer or user may usestandard login procedures such as digital IDs (X.509), SSL, and/orclient authentication. In certain embodiments, the distinguished name(DN) must be authorized for Web access in the master data of theconsolidator/iCSP. The user may then select a client (customer) or, ifthe user has no clients, directly select the consolidated list of bills(GetListOfBills) of the customer for whom he has logged in (step 620).In response, the user may be able to access the following exemplary datarelating to the bills: invoice reference, biller name, billers bankingaccount, due date, amount with currency, business transaction (bill)state (such as “open,” “dunning,” “due,” “scheduled,” “paid,” or “paidwith different amount,”). In certain embodiments, the user may be ableto select a hyperlink which will allow the user to access additionalinformation relating to the bill (step 630). The hyperlink may redirectthe user to an information page of the biller, normally hosted on theBSP. Such redirection may take place over a secure connection, such asone using SSL. As an alternative, the page can also be on a web serverof the biller.

The BSP authenticates the customer (step 635). Authentication may beperformed based on a token that may have been generated at the time thebill details were prepared and/or passed on as part of the bill summarywhich is passed back to the BSP together with the hyperlink. If thecustomer requested strong authentication, the bill may be presented onlyif the authentication matches one of the certificates, which may havebeen specified in the CustomerInfoResponse transmitted from theConsolidator/iCSP to the BSP in step 520 of FIG. 5. The BSP may maintaina number of HTML templates and may select a template based on thereferenced business transaction (bill). The template may indicatebusiness transaction data to be filled in. For example, the bill may bepersonalized with the biller's advertisements or advertisements ofaffiliated third parties. The third party advertisements to add may bechosen, for example, based on the customer information. For example, thecustomer's zip code may be used to select advertisements of thirdparties doing business in the customer's zip code. The generated HTMLpage comprises a hyperlink to the itemized bill. The customer selectsthe hyperlink to the itemized bill (step 645) and receives (afterauthentication) the bill (step 650). The bill may be, for example, inthe PDF format.

FIG. 7 is a flow diagram of an exemplary process for registering acustomer for an electronic billing (e-billing) process consistent withthe present invention. The customer or a user logs in at the CSP/iCSP(step 710). The customer or user may use standard login procedures suchas digital IDs (X.509), SSL, and/or client authentication. In certainembodiments, the DN must be authorized for Web access in the master dataof the consolidator/iCSP. The user may then select a client (customer)or, if the user has no clients, directly select the consolidated list ofbills (GetListOfBillers) (step 720). The consolidator/iCSP may possessan HTML template containing information of electronic billers. The listmay be completed with logos and biller data from the BSP usinghyperlinks (alternatively the data may be maintained locally on theconsolidator) (step 730). The presented list also contains a customerregistration status at the respective biller (inactive, active,registration_requested, registration_refused). The registration statusmay be stored, for example, in a BCR table (Biller Customer Relation) onthe Consolidator.

The customer selects a biller (step 740). The URL for the registrationform may redirect the customer to the BSP or to a Biller Web server(step 750). The BSP (or Biller Web server) identifies the customer,verifies and completes the customer information (step 760). The BSP mayverify the customer and complete the customer information by, forexample, obtaining a customer PID (Partner Identification Number) fromthe URL. If the customer cannot be authenticated, the BSP may getcustomer master data matching the received PID from the Consolidator. Apersonalized registration form (CustomerInfoRequest) may be transmittedto the Consolidator/iCSP (step 770).

A registration form is completed and posted (step 780). The registrationform may be presented, for example, using biller-specific HTML templatesand containing master data of the customer (not editable). Theregistration form may comprise buttons to register or cancel theregistration. Additionally, other information such as the BCN (Biller'sCustomer Number or debtor number) may be included. If the customerprocesses the bill in an ERP system, the registration form may beextended by a field to allow entry of a CBN (Customer's BillerNumber=creditor number). The customer completes the registration formand sends it back to the BSP (step 785). The BSP creates a BCR entry inthe consolidator with, for example, the status “registration_requested”(step 795). The BSP may optionally notify the biller (such as by E-Mail)about the new registration (step 796). The BSP may also send informationto the Consolidator/iCSP (in the form of, for example, aCreateBCRRequest) (step 797) which allows the Consolidator/iCSP tocreate a new BCR (step 798).

FIG. 8 is a flow diagram of an exemplary process for activating aregistering of a customer by a biller consistent with the presentinvention. The biller or a user logs in at the CSP/iCSP (step 810). Thebiller or user may use standard login procedures such as digital IDs(X.509), SSL, and/or client authentication. In certain embodiments, theDN must be authorized for Web access in the master data of theconsolidator/iCSP. The user may then select a client (biller) and arequest is sent to the BSP (GetBCRList) (step 820). If the user has noclients, the user may define filter criteria for getting a list ofcustomers (step 830). The BSP sends a request onto the consolidator/iCSP(GetBCRList) (step 840). The BSP also processes the consolidator/iCSP'sresponse (step 850) and presents a list of customers to the biller (step830). The biller checks and verifies the customer information onrequested registrations (step 860). For example, a mismatch in the BCNand the customer name should be avoided. If the registration data iscorrect, the biller may send an indication to the BSP to set the BCRstatus to active (step 870). The BSP may then set the BCR state on theconsolidator/iCSP by, for example, transmitting to the consolidator/iCSPa SetBCRState request (step 880). After setting the proper state in theBCR table, the consolidator/iCSP may optionally notify the customer(such as by E-Mail) (step 890).

FIG. 9 is a block diagram of an exemplary table for mapping the IDs of abiller for a customer to the IDs of a customer for a biller. Methods andsystems consistent with the present invention facilitate the integrationof Billers and Customers ERP systems. For example, a BCN (BillersCustomer Number) or debtor number may be stored in the consolidator/iCSPsystem. This enables the Biller to use existing Customer identificationsin billing data sent to the BSP. Expensive mappings can be reduced oravoided. Based on the information acquired in the customer registrationprocess, the consolidator/iCSP can map the BCN to a unique Customeridentification (e.g. the CPID, Customer Partner Identification).

In another example, the CBN (Customers Biller Number), a creditor numberused in the customer's ERP system to identify the biller, may also bestored in the consolidator/iCSP during the customer registrationprocess. This allows the BSP to map a BPID (Biller PartnerIdentification) directly to a Biller ID, known by the Customer ERPsystem during conversion on the BSP. Thus, in certain embodiments, thecustomer would not need to implement difficult and expensive mapping ofIDs.

FIG. 10 is a block diagram showing integration of e-banking into anelectronic bill presentment and paying system consistent with thepresent invention. E-Banking solutions can integrate bill presentmentusing, for example, a CCX (Consolidator CSP Exchange) interface.Customer may use multiple CSP's (Multi-banking). For example, the CSPcan fetch the current list of bills at the consolidator/iCSP forpresentment, instead of the bills being routed by the CSP. This wouldprovide a customer with the ability to view and pay his bills fromdifferent CSP's (e.g. banks)

FIGS. 11 and 12 are a flow diagram of an exemplary process forinitiating and performing a bill review by a customer consistent withthe present invention. An employee of the customer, defined here as thedispatcher, may log in at the consolidator/iCSP (step 1105) and selectone or more bills (step 1110). For bills not yet prepared for the reviewworkflow, the dispatcher can select a SetUpReviewWorkflow (step 1115).The dispatcher may be presented with a form that allows the dispatcherto identify one or more reviewers. The dispatcher may identify one ormore reviewers by, for example, entering a list of E-mail address (oraliases). The dispatcher can also enter other information, such asquestions, or assign bill items. In parallel, the dispatcher can havethe itemized bill presented.

The dispatcher sends the form back to the consolidator/iCSP(PostReviewForm) (step 1120). Based on the information provided, theconsolidator/iCSP may send an E-mail to each of the indicated reviewers(steps 1125, 1126). For additional security, the email may betransmitted using encryption or a private (in-house) network). The emailmay contain a hyperlink (URL) to the work item review bill and a short(customizable) description. Optionally, the email may contain anauthentication token. The status of the business transaction is changedto “bill review”.

The E-mail receiver (the reviewer) may connect to the consolidator/iCSPby, for example, the URL listed in the E-mail. For additional security,the iCSP may authenticate the reviewer by, for example, using SSL clientauthentication (step 1130). The received certificate may, for example,be compared with authorized certificates in the master data.Alternatively, the consolidator/iCSP may authorize the user based on atoken in the URL or authenticates the user based on another process,such as a user-id/password mechanism. The customer may receive thereview form with additional data (steps (1135, 1136) The review form mayalso contains a hyperlink to additional bill information. The user mayadd comments and accounting information with respect to bill contents(step 1140). For example, the user may comment that certain positionswere not received, other positions were ok, or provide instructions tocharge to internal account No. XYZ.

The completed form is sent back to the consolidator/iCSP(PostReviewForm) (steps 1145, 1146). Other reviewers may process theirworkflow item in a similar way. The dispatcher or any other authorizeduser may access the review form via list of bills at any time. Thesystem sends a message to a predefined address, once all reviewers haveposted the review form and sets the state of the business transaction to“open” or “due” depending on the due date. The reviewers do not need tohave access to any other bills or the list of bills. In certainembodiments, only the authentication/authorization has to be stored inthe consolidator/iCSP. For example, for reviewers with digital IDs, onlythe reviewer's DN has to be stored combined with the right for billreviews.

FIG. 13 is a block diagram of an exemplary archiving process for data ofbillers or customers. As shown in FIG. 13, an archive may be deliveredto the biller or the biller may retrieve an archive (step 1305). Thearchive may be in the form of a CD, DVD ROM, or another storage mediumcontaining a record of the biller's business transactions (bills) withthe BSP. An archive may also be delivered to the customer or thecustomer may receive an archive containing a record of the customer'sbusiness transactions with the consolidator/iCSP (step 1310). The PSPand a support organization may also receive an archive, containing theirown data.

As shown in FIG. 13, archive 1320 may comprise, for example, an index.The index may contain, for example, bill summaries of the businesstransactions in the archive. Archive 1320 may also comprise a businesstransaction report which may contain, for example, a bill summary, ahistory of all business transaction events, and hyperlinks to theoriginal messages.

The index may be digitally signed by, for example, the BSP and/or theConsolidator/iCSP. Digital signatures help to ascertain that the archivecontent has not been altered. Exchanged messages, such as the invoice,may also be digitally signed.

Optionally, other cryptographic mechanisms may be applied to avoid anychanges of the content of the archive. The archive may be delivered toor retrieved periodically, according to the requirements of the billeror customer. In certain embodiments, the receiver may confirmreadability of a received archive by sending a message indicatingreceipt and acceptance. In certain embodiments, business transactionsmay be removed from the BSP and/or consolidator/iCSP after certainconditions have been met, such as receiving all necessary acceptancemessages or after a configurable number of days. In certain embodiments,the archived data should be structured so as to meet the requirements oflocal state or federal regulations, such as those required for thereimbursement of VAT.

Modifications and adaptations of the present invention will be apparentto those skilled in the art from consideration of the specification andpractice of the invention disclosed herein. The foregoing description ofan implementation of the invention has been presented for purposes ofillustration and description. It is not exhaustive and does not limitthe invention to the precise form disclosed. Modifications andvariations are possible in light of the above teachings or may beacquired from the practicing of the invention. For example, thedescribed implementation includes software, but systems and methodsconsistent with the present invention may be implemented as acombination of hardware and software or in hardware alone. Additionally,although aspects of the present invention are described as being storedin memory, one skilled in the art will appreciate that these aspects canalso be stored on other types of computer-readable media, such assecondary storage devices, for example, hard disks, floppy disks, orCD-ROM; the Internet or other propagation medium; or other forms of RAMor ROM. It is intended that the specification and examples be consideredas exemplary only, with a true scope and spirit of the invention beingindicated by the following claims.

Computer programs based on the written description and flow charts ofthis invention are within the skill of an experienced developer. Thevarious programs or program modules can be created using any of thetechniques known to one skilled in the art or can be designed inconnection with existing software. For example, programs or programmodules can be designed in or by ®Java, C++, HTML, XML, or HTML withincluded Java applets or in SAP R/3 or ABAP. One or more of such modulescan be integrated in existing e-mail or browser software.

1. A computer-implemented method for processing bills electronically,wherein a transformed bill is created for a customer using master dataof a biller and master data of the customer, the method comprising:receiving, by a consolidator computer, a bill generated by a billerservice provider computer based on the master data of the biller,wherein the biller service provider computer has direct access to themaster data of the biller and the biller service provider computer doesnot have direct access to the master data of the customer; transforming,by the consolidator computer, the bill into a presentment formatspecified in the master data of the customer, wherein the consolidatorcomputer has direct access to the master data of the customer.
 2. Themethod of claim 1, wherein the consolidator computer does not havedirect access to the master data of the biller.
 3. The method of claim1, further comprising presenting or delivering the transformed bill tothe customer.
 4. The method of claim 1, further comprising digitallysigning the transformed bill by the biller service provider computer. 5.The method of claim 3, further comprising encrypting the transformedbill before presenting or delivering the transformed bill to thecustomer.
 6. The method of claim 1, further comprising archiving thetransformed bill by the biller service provider computer and/or theconsolidator computer.
 7. The method of claim 1, wherein the billerservice provider computer further receives billing informationcomprising one or more of information related to the biller, informationrelated to the customer, information related to a payment supplier,payment information, Value Added Tax (VAT) information, itemized billingpositions with relation to purchase order, and accounting information.8. The method of claim 1, wherein the master data of the billercomprises one or more of address information, data format information,information on communication addresses, bank and bank accountinformation, user authentication information, user authorizationsinformation, information on options for archiving services, options forprint services, and options for notifications.
 9. The method of claim 1,wherein the master data of the customer comprises one or more of addressinformation, data format information, communication addresses, bank andbank account information, user authentication information, userauthorizations, information on options for archiving services, andoptions for notifications.
 10. The method of claim 1, further comprisingdirectly transforming the bill from a biller format used by the billerinto a customer format as specified in the master data of the customerwithout using an intermediate format.
 11. The method of claim 1, furthercomprising providing a verification mechanism for the customer to verifywhether the biller service provider computer has the authority togenerate bills for the customer.
 12. The method of claim 1, furthercomprising registering the customer, wherein registering the customercomprises: receiving, from the customer, a selection of the biller;recording a registration relationship between the customer and thebiller, based on which the customer can receive bills from the biller.13. The method of claim 12, wherein registering the customer furthercomprises forwarding the registration relationship to the biller andreceiving, from the biller, an indication to activate a relationshipbetween the biller and the customer.
 14. A non-transitory computerreadable medium encoded with a computer program product, wherein thecomputer program product, when executed by a computer, causes thecomputer to perform the computer-implemented method of claim
 1. 15. Acomputer-implemented bill processing system configured to create atransformed bill for a customer using master data of a biller and masterdata of the customer, the system comprising: a biller service providermodule configured to have direct access to the master data of the billerand not have direct access to the master data of the customer andfurther configured to generate a bill based on the master data of thebiller; and a consolidator module configured to have direct access tothe master data of the customer and further configured to receive thebill and transform the bill into a presentment format specified in themaster data of the customer.
 16. The system of claim 15, wherein theconsolidator module is further configured to not have direct access tothe master data of the biller.
 17. The system of claim 15, wherein thebiller service provider module is further configured to receive billinginformation comprising one or more of information related to the biller,information related to the customer, information related to a paymentsupplier, payment information, Value Added Tax (VAT) information,itemized billing positions with relation to purchase order, andaccounting information.
 18. The system of claim 15, wherein the masterdata of the biller comprises one or more of address information, dataformat information, information on communication addresses, bank andbank account information, user authentication information, userauthorizations information, information on options for archivingservices, options for print services, and options for notifications. 19.The system of claim 15, wherein the master data of the customercomprises one or more of address information, data format information,communication addresses, bank and bank account information, userauthentication information, user authorizations, information on optionsfor archiving services, and options for notifications.
 20. The system ofclaim 15, further comprising a registration module configured toreceive, from the customer, a selection of the biller and to record aregistration relationship between the customer and the biller, based onwhich the customer can receive bills from the biller.